Skip to content

Conversation

sakgoyal
Copy link
Contributor

@sakgoyal sakgoyal commented Oct 9, 2025

Redoing #5232 because I messed up the force push.

Allow C++ compilers to compile this code without separately linking as a C library.

Changes:

  • Backport RGFW unicode fix
  • Add C-style casting where necessary
  • Fix a initializer list being in the wrong order (C++ requires declaration order)
  • GLFW currently has issues with cross compiling so I am using RGFW for now
  • Change C Aggregate initializer to C++ default initializer.

TODO:

  • Do not modify external libraries. update them instead
    • jar_* is ok to update. Managed by raysan5
  • C++ = {0}
    • maybe consider -ftrivial-auto-var-init=zero or something instead

@raysan5
Copy link
Owner

raysan5 commented Oct 14, 2025

@sakgoyal Added some review comments, just noticed that most are already listed on the TODO. Please, let me know when ready to merge. Thanks!

@sakgoyal sakgoyal marked this pull request as ready for review October 14, 2025 15:58
@sakgoyal
Copy link
Contributor Author

sakgoyal commented Oct 14, 2025

I don't want to update some of the dependencies. Many of them seem to introduce breaking changes that need more work to get working again that feels out of scope for this PR.

All workflows passed:
https://github.com/sakgoyal/raylib/actions

@raysan5
Copy link
Owner

raysan5 commented Oct 14, 2025

@sakgoyal added some minor tweaks to review

@sakgoyal
Copy link
Contributor Author

There could be another CI action for checking formatting (NOT a commit hook).

It would reduce a lot of back and forth.

@raysan5
Copy link
Owner

raysan5 commented Oct 14, 2025

@sakgoyal sure! but it needs to be coded!

@Peter0x44
Copy link
Contributor

Just wondering, why is this preferable to building/linking as C?

@orcmid
Copy link
Contributor

orcmid commented Oct 15, 2025

@Peter0x44 > Just wondering, why is this preferable to building/linking as C?
I also think the fascination with Clang is concerning. I have not delved into this, but it seems to me that the clean level of maintenance with Standard C Language will avoid confusions across platforms and choices of tools and misunderstandings of others who have a preferred language/compiler, etc.

I thought the provision of C++ bindings that have been made available as add-ons would be a preferable route. It isolates the language-preference and avoids the clean raylib source being mis-maintained by folks who are less equipped to preserve raylib portability to platforms other than the only one they know.

@Peter0x44
Copy link
Contributor

I also think the fascination with Clang is concerning.

Not being your preference of compiler doesn't make supporting it invalid.
But, it already worked. Perfectly fine.

@orcmid
Copy link
Contributor

orcmid commented Oct 15, 2025

@Peter0x44

Not being your preference of compiler doesn't make supporting it invalid. But, it already worked. Perfectly fine.

I agree, compiler shouldn't matter so long as portability is maintained.

But edits (especially significant ones) not intended to break anything still have to be reviewed. No fun.

@raysan5 raysan5 merged commit adfe2c1 into raysan5:master Oct 15, 2025
@raysan5
Copy link
Owner

raysan5 commented Oct 15, 2025

@sakgoyal thanks for the review, it looks good, most of the small tweaks seem related to C code quality following with pointer casting when required. Just note that if external libraries are updated, some of those changes can be overwriten.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants